FIG. 1 shows a possible architecture of a mobile device 10, such as a smartphone or a tablet.
Generally, the mobile device 10 comprises one or more processors 102 connected to one or more memories 104. The mobile device 10 comprises moreover at least on mobile communication interface 106 for communication with a base station BS, and a user interface 110, such as a touchscreen. For example, the mobile communication interface 106 may comprise a GSM (Global System for Mobile Communications), CDMA (Code Division Multiple Access) transceiver, W-CDMA (Wideband Code Division Multiple Access), UMTS (Universal Mobile Telecommunications System), HSPA (High-Speed Packet Access) or LTE (Long Term Evolution) transceiver.
For example, in the memory 104 may be stored an operating system OS being executed by the processor 102 and which manages the general functions of the mobile device 10, such as the management of the user interface 110 and the establishment of a connection to the base station BS via the interface 106. The memory 104 may also contain applications being executed by the operating system OS. For example the memory 104 may comprise a web browser application WB.
For establishing a connection with the base station BS, the mobile device 10 is coupled to a processing unit 108 configured to manage the identity identification of the user. For example, usually the mobile device comprises a card holder for receiving a card comprising a Subscriber Identity Module (SIM), which is usually called SIM card. Generally a corresponding module may also be installed directly within the mobile device 10.
For example, nowadays is often used a Universal Integrated Circuit Card (UICC) 108, which is a smart card often used in GSM and UMTS networks. The UICC ensures the integrity and security of all kinds of personal data and typically holds a few hundred kilobytes.
For example, in a GSM network, the UICC 108 contains a SIM application and in a UMTS network a USIM application. A UICC may contain several applications, making it possible for the same smart card to give access to both GSM and UMTS networks, and may also provide storage of a phone book and other applications.
Thus, generally, also the UICC 108 comprises at least one processing unit and at least one memory and permits the execution of applications directly within the UICC.
As mentioned in the foregoing, the UICC may be integrated directly in the mobile device and is in this case often called embedded UICC (eUICC).
Generally, also other applications may be stored on the UICC, which may also communicate with remote hosts.
Specifically, as shown in FIG. 2, the processing module 108 often comprises one or more processors 1082 and one or more memories 1084 for executing applications stored in the memory 1084 of the module 108.
For example, the UICC 108 may comprise in addition to the Subscriber Identity Module application (reference sign SIM in FIG. 2) at least one further application APP. For example, this application APP may be configured to communicate (directly or indirectly via the processor 102 and possibly the operating system OS) with the communication interface 106 in order to send data to and receive data from the remote host 30.
For this purpose, the host 30 may be connected via a network 20, such as a Local Area Network (LAN) or a Wide Area Network (WAN), such as the internet, to the base station BS. Accordingly, connection between the host 30 and the UICC 108 may be established by means of the network 20, the base station BS and the communication interface 106.
Generally, the communication may be initiated by the host 30 or the UICC 108.
For example, the application APP may be a web server application, which receives requests from the web browser WB of the mobile device 10 and obtains respective content from a remote host 30, such as a web server.
The application APP may also be an authentication application. In this case, the host 30 may send an authentication request to the UICC 108 and the UICC 108 may send an authentication response to the host 30.
FIG. 3 shows in this respect a typical architecture of the software layers of a UICC card.
Substantially, the UICC 108 comprises a hardware layer UICC_HW being represented (at least) by the processor 1082 and the memory 1084. On top of the hardware layer UICC_HW runs the operating system UICC_OS of the UICC card.
The operating system UICC_OS may manage a plurality of applications.
Specifically, in the example considered, a Java Card System JCS is executed by the operating system UICC_OS, which manages and runs applets, i.e., applications using the APIs (Application Programming Interface) provided by the Java Card System JCS.
For example, the Java Card System JCS comprises usually a SIM and/or USIM API (identified with the reference sign (U)SIM API) which manages the basic Subscriber Identity Module commands and provides functions to higher level SIM or USIM applets (identified with the reference sign (U)SIM_APP).
Generally, the communication with the remote host 30 may be performed via SMS (Short Message Service) or by means of a Bearer Independent Protocol (BIP), such as GPRS, EDGE, or UMTS. Accordingly, often the Java Card System JCS comprises a Bearer Independent Protocol API BIP.
The Java Card™ Platform provides a JAVA™ runtime environment, which is particularly optimized for smart cards. This technology is well known to those skilled in the art, rendering a more detailed description herein superfluous.
Often the Java Card System JCS comprises a GlobalPlatform module GP according to the “GlobalPlatform Card specification”, e.g. version 2.2.1. Also this standard is well known to those skilled in the art, rendering a more detailed description herein superfluous. Basically, the GP module provides features such as user authentication through secure channels, or the installation and remote management of the applets. For example, one of the possible encryption mechanisms managed by the GP module may be the SCP (Secure Channel Protocol) 80 specified in the technical specification ETSI TS 102.225 “Smart Cards; Secured packet structure for UICC based applications”, e.g. version 9.0.0.
The above mentioned API functions may then be used by the applets, such as the SIM or USIM applet (U)SIM_APP, a basic applet B_APP and/or a secure applet S_APP.
The UICC 108 may comprise also further applications, such as a Smart Card Web Server SCWS and possible Web server applets SCWS_APP, which, e.g., perform the above mentioned web server function.
Generally, the UICC 108 may comprise not only custom applets but also native low level applications N_APP being executed directly by the operating system UICC_OS.
FIG. 4 shows a typical communication by using the remote management protocol SCP 80 as specified in the technical specifications ETSI TS 102.225 “Smart Cards; Secured packet structure for UICC based applications”, e.g. version 9.0.0, and in particular in ETSI TS 102.226 “Smart Cards; RemoteAPDUstructure for UICC based applications”, e.g. version 9.2.0.
In the example considered, the remote host 30 may send a command, i.e. a Command Application Protocol Data Unit C-APDU, to a secure application S_APP installed on the UICC 108, and receive, from the application S_APP a respective response, i.e. a Response Application Protocol Data Unit R-APDU.
Specifically, in the example considered is used the protocol SCP 80. In this case, the host 30 sends the command C-APDU to a Short Message Service—Service Centre SMS-SC, which encrypts the command C-APDU using SCP80 and encapsulates the encrypted content in a SMS message, which is transmitted to the UICC 108 by means of the base station BS and the mobile device 10. The UICC 108, possibly by using the functions provided by the operating system UICC_OS and the Java Card System JCS, decrypts the content of the SMS message and forwards the content C-APDU to the secure application S_APP.
By means of the SCP80 protocol the host 30 can request a Proof of Receipt (PoR) to the secure application S_APP. Only in this case the secure application S_APP can send the response R-APDU to the host 30 appropriately secured (e.g. by means of the ETSI 102 241 API). Specifically, the secure application S_APP instructs the operating system UICC_OS to encapsulate and encrypt the R-APDU response in the field “additional data” of the PoR message using the SCP80 protocol. The PoR message is in turn encapsulated in an SMS message which is transmitted to the service centre SMS-SC by means of the mobile device 10 and the base station BS. The service centre SMS-SC decrypts the content of the SMS message containing the PoR and forwards the content R-APDU to the host 30.